mostly lgtm

Unfortunately, this does not work with initdata: An attacker can launch the VM with TEE support and set HOSTDATA to their desired value, but supply an initdata file that includes Insecure. HOSTDATA is now unvalidated, but still shows in reports.

The previous version was arguably safer, but safe enough? idk.

I just have one nit, LGTM otherwise.

lgtm, just a nit and a squash

Thanks, an inline comment and some others that I had looking at the merged PRs so far, so feel free to incorporate as you see fit here/in one of the upcoming PRs/follow-ups:

• I think the relevant PR is already merged by now but raising this, this line here:
  

  contrast/cli/verifier/cpu_count_valid.go

  Line 23 in 25c0a71

  if spec == nil || spec.RuntimeClassName == nil || !strings.HasPrefix(*spec.RuntimeClassName, "contrast-cc") {

  
  is not using the IsContrastPod helper, so insecure pods bypass that CPU count check.

• The insecure validator https://github.com/edgelesssys/contrast/blob/main/internal/attestation/insecure/validator.go is not logging any message (using the logger) like the other validators. I think we would want to see in the logs at least:

  • when an insecure attestation is accepted
  • log on entry/exit (like the rest)

• I noticed insecure configurations use the snp name in

  contrast/nodeinstaller/internal/targetconfig/targetconfig.go

  Line 40 in 25c0a71

  conf.kataConfigPath = filepath.Join(runtimeBase, "etc", "configuration-qemu-snp.toml")

  . Shouldn't we rename these to something more fitting like configuration-qemu-bm.toml?

• This is a readability nit but it took me a minute to parse

  contrast/internal/manifest/runtimehandler.go

  Line 46 in 25c0a71

  if len(parts) < 3 || len(parts) > 5 {

  I would either add a comment explaining the bounds or make the range prefix-aware i.e minParts, maxParts := 4, 5; if isInsecure { minParts, maxParts = 3, 4 }